\section{Modélisation des données}
	\vspace{0.5cm}
	Plusieurs entités s'imposent d'elles même à la lecture de l'énoncé : il est par exemple évident que l'on devra manipuler des entités d'Association, d'Individu, et d'Evènement. 
	\vspace{0.5cm}	
	\subsection*{Individu}
	\vspace{0.5cm}
	On remarque qu'il y a différents acteurs humains, qui, à partir de caractéristiques communes, acquièrent d'autres attributs. 
	
	Dans un premier temps, chaque individu est représenté par un nom et un prénom. Cette entité, Individu, sera la classe de base dont chaque acteur humain héritera. Prise comme telle, elle représente les personnes extérieures à une association. 

	Ensuite viennent les Adhérents, caractérisés par un email, une filière et une promotion. Ceux ci se voient attribuer à chaque adhésion un login et un mot de passe. Comme ces attributs sont propres à chaque adhésion, et qu'un adhérent peut s'inscrire dans plusieurs associations, il est plus cohérent de relier ces deux champs directement à l'action d'adhérer. En plus de ces derniers, on retiendra le montant de la cotisation, et la date à laquelle elle a lieu. 
	
	Enfin, être adhérent à une association donne le droit de faire parti de son bureau, ce qui formera une nouvelle entité. Un individu peut être responsable dans plusieurs associations tant qu'il y est adhérent. Chaque responsable a un unique rôle, et peut poster des news, que les adhérents peuvent commenter. Les caractéristiques du commentaire concernant autant la news que celui qui la commente, ses attributs sont liés à l'association, et non aux entités.
	\vspace{0.5cm}	
	\subsection*{Evenement}
		\vspace{0.5cm}
		
	Une association peut organiser des évènements. Chaque évènement a un lieu, une date, différents tarifs... La plupart de ces informations vont constituer ses attributs. Cependant, certains lieux risquent d'être redondants (Enseirb-Matmeca, Nouvelle Salle ...). Il parait donc justifié de créer une entité à part décrivant un lieu. Chaque évènement sera donc lié à un seul et unique lieu. Nous avons fait le choix de rattacher l'attribut concernant le nombre de place maximal à l'entité Evenement, plut\^ot qu'au Lieu. En effet, suivant l'activité exercée (spectacle, compétition ...), le nombre de personnes pouvant participer peut différer, pour un m\^eme lieu. Nous avons donc jugé ceci plus réaliste.
	
	De la même manière, un évènement se produit à une certaine fréquence. Généralement ce sont des termes génériques : ponctuel, hebdomadaire etc., nous allons donc créer une entité supplémentaire pour spécifier la fréquence de l'évènement.
	
	L'intérêt d'un évènement étant de rassembler des gens, nous allons devoir différencier les individus participant à tel évènement des autres. Pour cela, une autre entité doit être établie. Chaque groupe de participants n'assiste qu'à un seul et unique évènement. Ensuite, chaque participant peut noter l'évènement auquel il a participé. Encore une fois, la valeur de la note étant propre à l'action de noter, cet attribut sera lié à l'association, et non à l'entité.
	
	Les adhérents à l'association organisatrice ont la possibilité de laisser des commentaires à propos de l'évènement, qu'ils y participent ou non. L'action de commenter sera décrite par une date et un texte.
	
	Enfin, un évènement peut avoir besoin de constituer une équipe qui veille au bon déroulement des activités. Les adhérents à l'association qui organise l'évènement pourront donc se réunir pour former celle-ci. Une équipe ne surveille qu'un évènement, mais un évènement peut être surveillé par un nombre non limité d'adhérents.

	\vspace{0.5cm}
\subsection*{Association}
	\vspace{0.5cm}
	
Les associations, noyau central de ce système, ont plusieurs caractéristiques. Chacune d'entre elles comptent des adhérents, qui lui sont liés par une adhésion, un bureau, des évènements qu'elle organise. Cependant, le seul attribut qui lui soit réellement propre est son nom. Le reste n'est visible que par les liaisons qu'elle a avec les autres entités.

Par exemple, une association a des objectifs à remplir. Leur nombre étant variable, ils sont représentés par une entité à part. Un objectif est lié à une seule association, et possède un nom, une description et un indicateur d'état. 

Une association a aussi des sources de financement. Encore une fois, celles ci pouvant être multiples, et commune à d'autres associations, elles sont représentées par une entité, définie par un nom. L'action de financer quant à elle nécessite un champ montant, ainsi qu'un champ date pour des besoins d'historique.
	\vspace{0.5cm}
\subsection*{Diagramme entité-association}
	\vspace{0.5cm}
Notre diagramme entité-relation a pris trois formes avant d'arriver à son stade final. \textit{Afin de ne pas créer d'espace vide inutiles, les dits diagrammes ont été placés en annexe.}

Le premier jet est visible en annexe \ref{first}.

	\vspace{0.5cm}
Pour parvenir à la deuxième version, visible en annexe \ref{second}, plusieurs modifications ont été apportées.
\begin{itemize}
\item[•] le login et le mot de passe, encore en suspens, ont été attribués à l'adhésion, et non à l'adhérent. 
\item[•] l'entité Etudiant a été renommée en Individu, terme plus général.

\item[•] l'association "se regroupe", qui reliait jusqu'alors les entités Adhérent, Etudiant et Participant est finalement devenu une liaison entre Individu et Participant. En effet, puisque Adhérent hérite d'Individu, lier les deux tables est inutile. 

\item[•] l'attribut "tarif" a été abandonné dans l'entité Participant car il suffit de savoir si l'individu est adhérent ou non pour choisir le bon tarif, disponible dans l'entité Evenement.

\item[•] l'attribut "montant" à l'origine contenu par l'entité Partenaire a été déplacé dans l'association qui la lie à l'entité Association. Un même partenaire peut apporter deux sources de financement différente, et le montant est plus relatif à l'action qu'à l'entité.

\item[•] les deux associations "commente" se sont vu ajouter un attribut "date", afin d'aborder une approche temporelle.

\item[•] l'attribut "rôle" de l'entité Responsable est devenu une entité à part entière, ce afin d'éviter une redondance.

\end{itemize}  
	\vspace{0.5cm}
Les modifications apportées ensuite au diagramme pour arriver à sa forme finale ont été plus succincte.

Dans un premier temps, toutes les entités se sont vues attribuer un identifiant pour faciliter la future implémentation en SQL. 

Ensuite, la cardinalité entre l'entité Equipe et Evenement étant 1,1 - 1,1, elles ont été fusionnées. C'est donc le fait de surveiller un évènement qui crée l'équipe, sans nécessiter la création d'une entité.

Dans la m\^eme idée, la relation entre Individu et Participant a été remplacée par une relation d'héritage, bien plus cohérente avec le reste de la modélisation.

Enfin, l'association "finance" a été enrichie d'un attribut "date" pour mieux représenter cette action, et permettre d'établir un historique, et l'entité News, d'un attribut "id\_association" afin de transcrire le fait qu'une news concerne une seule et unique association.

Cette version finale est visible en annexe \ref{third}.
